Invalid Date

WJansen

I pass a variable to the report as a string. f.e. '2-5-2011'. (May 2nd)
In fast report code this string is put to a Tdate variable using strToDate.
Now on my system this goes allright (I have regional settings to Dutch, where the format is: dd-mm-yyyy)
On a XP system at our customer's it is not OK. (also has regional settings to Dutch, no differences compared to my system)
He gets an '2-5-2011' is not a valid date' message.
On another PC (Vista) at the customer it is also working fine.
The message is generated from fast report, because I did some testing.
Strangely it als went wrong when I questioned:

DateToUse : TDate;
temp : string;

temp := DateToStr(now); //time was 02-05-2011 and temp gave '2-5-2011'
DateToUse := strToDate(temp);

or
temp := '2011-05-02'
temp := '2011-5-2'
temp := '2-5-2011'
temp := '02-05-2011'

???

Fast report version 4.9.1111

Now I remeber that regionalsettings are troublesome more often.
In our delphi project, upon initialising we perform a:

SetThreadLocale(GetUserDefaultLCID);
GetFormatSettings;

The PC has a Windows XP Professional 2002 OS, with SP3

What can be the case?

Mick.pl

You should use FR Date&Time functions to avoid problems you've mentioned.
Have a look at the example below:

var
     MyDate :TDateTime;                                                                          
begin
    MyDate := EncodeDate(2011,5,2);
    ShowMessage( DateToStr(MyDate));                                                 
end.

Mick

WJansen

Not to happy about this. Have you any clue why the date gives a problem?
Don't you believe this could be solved in Fast Reports?

Mick.pl wrote: »

You should use FR Date&Time functions to avoid problems you've mentioned.
Have a look at the example below:

var
     MyDate :TDateTime;                                                                          
begin
    MyDate := EncodeDate(2011,5,2);
    ShowMessage( DateToStr(MyDate));                                                 
end.

Mick

Mick.pl

Well, if I face a problem with a certain situation or unnormal behavior of programming language (and FR script is a kind of it) then I do not waste my time finding the root of this behavior or waiting till new version or new build will solve my problem. I try to find a solution immediatly which is not too complicated and gives me satisfactory results instead.

I've been working with dates for many years and I never trusted operating systems to manage with my date variables.

So I have to say sorry - I have no clue to explain what are you asking about [img]style_emoticons/<#EMO_DIR#>/sad.gif" style="vertical-align:middle" emoid=":(" border="0" alt="sad.gif" /> You can use my suggestion or you can ... keep on searching[/img][img]style_emoticons/<#EMO_DIR#>/smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" /> Mick[/img]

WJansen

I am very happy that you take the time to give me your solution.
Like you, I face troubles with date presentation and currency presentation as long as I do programming.
May be for you the solution did not implicate a lot,
but I am a bit stuck with having more than one customer using the reports customized already. When I change the variables to seperate day, month and year, they have to change their tailored reports as well.
That's why I am not happy. This problem pops up at one customer for some reason for the first time in years, whereas many others have no problems....

I am hoping someone at Fast Report is picking this up and was hoping you would agree that this behaviour can be considered a bug or may be something configured in the OS is NOK.

Mick.pl

I do agree with you that it is unnormal behavior - no matter if this is FR or internal Delphi StrToDate function. But this DOES NOT solve your problem. Maybe sending an offical support ticket directly to FR would be better choice than searching through this forum?

Consider your own StrToDate function: you always pass date as a string with dd-mm-yyyy format and your StrToDate function can recognize this string no matter what OS settings are [img]style_emoticons/<#EMO_DIR#>/smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" /> You've ended your first post with a question "what can be the case", and I understood you searched for a solution based on FR engine. I replied as I understood - suggestion to use EncodeDate instead of StrToDate, which was a source of error. If you don't get help quickly from FR team or someone else (about OS settings) than you'll still have to modify your customized reports because your end user gets an error message. Then you may write your own StrToDate user function or use EncodeDate - depends on what means less work for you.[/img]

wrote:

When I change the variables to seperate day, month and year, they have to change their tailored reports as well.

Does it mean your end user may design those reports and you only give them a kind of executably run-time that run those reports? If it is like that then when you change executably run-time (with new StrToDate function) none of reports will need to be changed

wrote:

May be for you the solution did not implicate a lot, but I am a bit stuck with having more than one customer using the reports customized already.

Our applications alltogether have over 500 reports (all by FR technology) and are used on several thousands PCs. And that's why we avoid any date conversion that we can NOT fully control.

Mick